[#serverlessdays 2019]AWSの事何も理解していなかった… Serverless Ingress Workshop :: AWS Workshopでスコア0だったので反省と今後の勉強の仕方を考えてみた

はじめに

おはようございます､加藤です｡ ServerlessDays Tokyo 2019 のWorkshop 01に参加したのですが､スコア0という悔しい結果になってしまったので､その反省と今後の勉強の仕方を考えてみます｡
本ブログの｢こうした方が良い｣という感想はスコアアタックという特殊な状況での感想です｡普段はやるべきで無い事を多数含んでいるのでご注意ください｡

内容はこんな感じです｡

• 3人でチームを組み課題にトライ
• サーバーレス縛り(ECSなどのコンピューティングリソース禁止)でバッチ処理を行う
• 自動採点システムによるスコアを競う(より速くより正確な物を作ることが目的)
  • 誤りがあるとマイナス評価
  • 時間経過でマイナス評価
• 制限時間は7時間
  • お昼休憩などは各チームで自由なタイミングで取る
• テンプレートやヒントなどは無し
  • 採点システムの仕様に関する案内や進め方についてのフォローは有り

3人ずつのチームに別れ､合計13チーム程でした｡しかし､得点できたチームはわずか3チームのみという結果で､冒頭に述べた通り私のチームもスコア0でした｡
スコア0というのは､ラフにも組めなかった...という事でものすごく悔しかったです...

自分のステータス

感想なので､主観的な記事になるのですが､それだけだと役に立たないと思うので簡単に私のIT業務経験年数を書いておきます｡

• オンプレインフラ構築: 2
• AWSインフラ構築・プリセールス: 1
• プログラミング: 4ヶ月

プログラミング4ヶ月とはいえ､IT業務経験はそれなりにあり､新卒という訳でも無いので頑張らないといけないです...

失敗したなと思うポイント

マネジメントコンソールで構築せずSAMを使った

チームメンバーと話しあい｢とにかく遅くても動くものを作ろう!｣というスタンスで進めていましたが､チームメンバー全員がSAMの経験があったし､後々での修正を考えるとSAMの方が楽そうと判断してしまいました｡
SAMをメインで担当したのは私なのですが､結果的に(私のSAM習熟度で)この判断は誤りでした｡

SAMを書いていると最中に､何度も｢あれ?あの項目ってなんて書くんだっけ？｣､｢デプロイ失敗したけどなんだろう？あ､必須項目が抜けていた｣という事が起こりました｡ドキュメントを見て修正はできるのですが､かなりの時間をロスしてしまい､コード担当者が実際に環境で動かし始めるのを遅らせてしまいました｡

普段､SAMを作る際は､以前使った物をコピペ＆改変や複数個作るリソースの場合､元々あるものをコピーして作ることが多いです｡
会社とは関係がない場で､業務で使っているSAMのコードをコピペして改変するという行為は危険だと判断し行いませんでした｡
SAMにはクレデンシャルな内容は記載しないので漏れて困るという物は無いのですが､

• 時間制限があり焦っている精神状態
  • 内容に問題がないかチェックする自分を信用できない
• AWS Cloud9で環境(およびリアルタイムでコード)を共有している
  • ローカルのエディタで改変してから貼り付け or 部分に分けて貼り付け する必要がある
• 貸与されているAWSアカウントにデプロイする
  • どのように管理されているか不明

こういった状況なので､一瞬｢コピペして作るか？｣と検討だけはしましたが､ゼロから作るしかないと決断しました｡

また､ラフにアーキテクチャ設計→構築→修正という風に素早く進める際に特に辛かったのがリソース再作成が必要なパラメータの変更です｡ 1つのリソースでこれが発生すると､スタックまるごと削除＆再作成が必要になりロスが大きかったです｡
以上のことから､こういったシチュエーションではマネジメントコンソールで作成した方が良いなと思いました｡

雑にでもテストを書いたほうが良かった

自分が主体となってコードを書くのでは無く､支援程度だったので浅い感想です｡
急ぐ場合でも､雑にテストを書いたほうが良いなと感じました｡その理由は､以下です｡

• AWSリソース→Lambdaへのイベント形式でつまずきがち
• 他メンバーが変更しようとした時にそもそも期待する動作の理解に時間がかかる

雑というのはこんな感じをイメージしています｡

• 正常系で1つのパターンのみ
  • インプットは実際に動かしてprintで内容を確認してコピペ
• 比較条件は緩くで良い

サービス間の連携になると悩む

サービス間の連携時の仕様について悩む事が多かったです｡サービス単体の仕様はパッと頭に浮かんだとしても､こういった要件で組み合わせに問題は無いか？というのが中々浮かばず､また調べる事にもサービス単体の仕様を調べるのと比べてより長くかかりました｡
パッと浮かばないのは経験不足､調べるのにも時間がかかるのは双方向の連携が可能なサービスだと半分は求めていない結果が返ってくる為だと思われます｡(自分のGoogle検索力も大きく関係しています)

良かったなと思うポイント

Cloud9でのモブプログラミングもどきは便利

• 別のPCを使う(別のPCから同じサーバーを使う)
• 会話がそこまで多くは無い

という感じだったので､もどきとしています｡

Cloud9で設定を行うことで､複数人で同時に同じ環境を同期的に仕様する事ができます｡
私が､SAMで環境変数を定義して､別の人がコードを書き続けている最中のコード､環境変数を取り込む処理を書いて｢これのテーブルを操作してね｣と伝える事でミス・ロスが起こりにくくなります｡
また､他の人って今何やっているんだ？って成った際にさっと覗きに行けます｡

これ変じゃない？手伝って欲しい！が言い合えた

席が近い人でチームを組むスタイルだったので､一人は同僚でしたがもうひとりの方は当然初対面です｡
ですが､｢ここ自信が無いので手伝って欲しい｣や｢これ変じゃない？｣を言い合えたのは､とてもよい関係性だったと思います｡

今後の勉強を考える

小さい物を0から沢山作る

｢なんで普段できている事ができないんだ...｣とすごく感じました､その理由を分解するとこうなります｡

• サービス間の連携の理解が足りない
• やりたいこと→アーキテクチャの変換が遅い
• 0から開発がしやすい状態に持っていくまでが遅い

これらの問題に対する対応として､小さい物を0から沢山作ろうと思います｡またその際には､参考元をコピペして修正ではなくドキュメントを見て自分で書く必要があると考えています｡
幸い作ってみたいチャットボットなどのネタはあるので､それに取り組もうと思います｡

作ったアーキテクチャを隅々まで動かしてみて確認

個人で作る物だと､色々とラフになりがちですが､実際に作った物を動かしてみて細部まで確認してみるつもりです｡
具体的には､メトリクスやログを確認して実際の動作を体に覚え込ませていくつもりです｡

あとがき

なにげに､ガッツり感想なブログを書いたのは､これが初めてな気がします｡ただ､それだけ今回のスコア0というのは悔しかったです...
Workshopって初心者向けだよねという先入観から､テンプレートがあって少しずつ改修みたいなスタイルと勝手に誤解しており､当日内容を聞いて衝撃を受けましたが､点数は取れるだろうと思っていましたが､惨敗でした｡
精進してきます!!